Internet Info 1993

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-iplpdn-multi-isdn-02.txt < prev next >

Wrap

Text File | 1993-09-02 | 20KB | 623 lines

Draft Encapsulation Determination August 1993 INTERNET DRAFT Expires: Februrary 16, 1994 Determination of Encapsulation of Multi-protocol Datagrams in Circuit-switched Environments Keith Sklower Computer Science Department University of California, Berkeley 1. Status of This Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appro- priate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. 2. Abstract This document enumerates the existing means for transmitting Internet Protocols across public data networks using cir- cuit-mode ISDN, and other switched services. It recommends limiting the choices to the three most common methods, from which one can determine which method is in use by inspection of the packets. The intention is to capture in a slightly more formal way the level of consensus reached at the 24th - 27th IETF meetings. 3. Acknowledgements The author specifically wishes to thank Clifford Frost and William Jolitz for many extensive discussions on the Sklower [Page 1] Draft Encapsulation Determination August 1993 subject, Gary Kessler for correcting errors in the encoding of LLC IE's, Glen Kime of Network Express for the secotion on inverted HDLC, and more generally the IP over Large Pub- lic Data Networks and PPP extensions working groups, whose deliberations this memo is supposed to reflect. References are made to earlier work by Leifer et al. [1], and Murakami et al. [2]. 4. Conventions The following language conventions are used in the items of specification in this document: o MUST, SHALL or MANDATORY -- the item is an absolute requirement of the specification. o SHOULD or RECOMMENDED -- the item should generally be followed for all but exceptional circumstances. o MAY or OPTIONAL -- the item is truly optional and may be followed or ignored according to the needs of the implementor. 5. Introduction The advent of Circuit-mode ISDN has provided the possibility of much higher rates of information exchange than previously possible over modems and voice-grade lines. We anticipate the use of this technology to encourage ``tele-commuting'' (making it more possible for people to work effectively at home), and to reduce the cost of data communications in businesses having geographically dispersed sites. Other applications, such as multi-media conferencing, are much more economically feasible than before. The contribution by Murakami also cites the use of ISDN to acquire additional bandwidth for handling excess traffic in parallel with leased lines, and more generally back-up of a failed leased line. Given the newness of the technology, the diversity of its applications, and its wide availability, it is not surpris- ing that a number of incompatible link level protocols are coming into use for the transmission of data over ISDN links. Examples are the use of SLIP [3] and PPP [4,5] over asynchronous terminal adapters using V.120 [6], PPP over synchronous terminal adapters using V.120 or directly over the B channel via native ISDN interfaces [13], and both the Multiprotocol Encapsulation over X.25 [7], or Mutltiprocol Encapsulation over Frame Relay [8] directly on the B chan- nel. There are even other examples cited in Murakami's paper. Sklower [Page 2] Draft Encapsulation Determination August 1993 In this paper we recommend limiting the choice of encapsula- tions to those described in RFC 1294 (Frame Relay), RFC 1331 (PPP), and RFC 1356 (X.25). The contribution by Murakami suggests using out-of-band sig- naling for negotiating the link-layer protocol and other configuration parameters using ISDN Information Elements such as UUI and BC. It is the experience of the members of the IPLPDN that ISDN implementation are as yet so diverse, the deployment of Switching System 7 so limited, and sub- scription policies by the regional providers so different, that user cannot depend on having these information elements passed end-to-end. The likeliest element to be passed end- to-end is LLC; this memo proposes a method for chosing the link-layer protocol based on this element when available. Where it is not available, an algorithm is proposed for ``negotiating'' the protocol by in-band exchange of data. Other configuration parameters can be negotiated in band using PPP, even for the Frame Relay and X.25 cases, as described in PNMI[9]. 6. Principal Recommendations 6.1. RFC 1294 6.1.1. Specific Encoding RFC 1294 specifies the transmission of datagrams in a format according to Q.922. As this is an HDLC framing, it is com- pletely suitable for use on an ISDN B channel. The RFC does not describe how the Q.922 header is generated; it was assumed that a genuine frame relay would provide it as a normal consequence of its operation. All other details of the encapsulation were completely specified by this RFC. In fact, it is possible to employ ISDN to gain access to a Frame Relay, and when doing so packets received from it will contain a valid DLCI. Obviously, a system communicating with a frame relay must set the DLCI's appropriately. When transmitting datagrams across an ISDN B-channel using this format between systems which are not Frame Relays, such systems MUST provide a valid DLCI header. As such, the low- est order bit of the first byte transmitted MUST be zero. The DLCI may be configured by prior agreement to any accept- able value. A default DLCI value of 16 is consistent with current ANSI recommendations (T1.617), however at some future time when frame relay service is offered over the D channel, the default DLCI value should be 512 (T1.618). Sklower [Page 3] Draft Encapsulation Determination August 1993 6.1.2. Advantages of Frame Relay Encapsulation A primary advantage for Frame Relay Encapsulation is that communication providers such as the Regional Bell Operating Companies may be able to offer ISDN accessible frame relay service which is high integrated with the voice switching fabric. Proponents for this method have claimed that RFC 1294 encap- sulation is very simple to implement; in fact it is possible to prepend a fixed header to all datagrams sent, and com- pletely ignore the first few bytes of any datagram received. When systems have been compatibly preconfigured, no further state must be maintained on a per B-channel basis. This is clearly of concern for circumstances like multiple primary rate interfaces coming into a single router, thus poten- tially supporting hundreds of B-Channels. Furthermore, it is possible to start transmitting data as soon as the circuit has been established, thereby reducing latency. PPP and X.25, by contrast require an exchange of packets to declare the link up. However, to be fair, changes have been proposed to PPP suggesting that it too may be manually configured, and in such cases may not require the usual exchange of packets 6.2. PPP The proponents for PPP argue that it is widely implemented, and constructed in such a way to force interoperability. The details of the protocol are completely specified by RFC's 1331 and 1332, and are also applicable to any situa- tion where synchronous transmission of data is possible. They argue that any commercial router one procures is likely already to have code supporting PPP, and it is flexible enough to adapt to all the situations cited as applications in this memo. 6.3. RFC 1356/B-Channel X.25 Systems supporting exchanging information according to OSI conventions are required to support X.25 over the B-channel, and RFC 1356 provides means for conveying Internet Protocols in this situation. 7. In-Band Link Protocol Determination The algorithm is that the caller starts transmitting data or negotiation according to his preferred encapsulation, and the callee just figures out what is desired by inspection of the first correctly framed HDLC packet. If either the caller or callee selects PPP or X.25, they will be required Sklower [Page 4] Draft Encapsulation Determination August 1993 to retransmit either PPP LCPs or X.25 SABM until they time out. 7.1. Caller's Algorithm A system wishing to exchange information using RFC-1294 encapsulation MUST transmit some packet with a valid two- byte DLCI. The calling system MAY transmit protocol data immediately, given suitable preconfiguration. The calling system MAY also initiate parameter negotiation according to PNMI, using the RFC-1294 encapsulation. A system wishing to exchange information using PPP will issue an LCP packet in native PPP format, according to the requirements of RFC 1331; i.e. the first byte will be 0xff, and the second byte will be 0x3, etc. A system wishing to use X.25 will issue a SABM with an address of station A, according to the OSI implementors agreement [10]. 7.2. Callee's Algorithm The called system will wait until it has received a cor- rectly framed and checksummed HDLC packet and inspect the very first byte. PPP requires that the station address be all ones (0xff). Conventional X.25 HDLC requires a station address of either 1 or 3. The 2,3 or 4 byte DLCI Q.922 for- mats all require that the low order bit of the first byte to be zero. Thus, it is possible for a called system support- ing all three methods to unambiguously determine which encapsulation is desired and respond in the appropriate man- ner. In the past, many networks required that CPE that sent digi- tal data maintain a minimum one's density. One of the com- mon methods of achieving this was to use inverted HDLC data. Inverted HDLC data was the simple inversion of the output of the transmitter. Because HDLC data cannot have more than 5 ones in a row (Abort avoidance). Consequently, inverting HDLC data guarantees no more than 5 zeroes in a row, meeting one's density. Even though this restriction no longer applies on B8ZS lines, some installed equipment still use data inversion. The following details a method which the receiver of a call may use to discriminate between equipment using normal (non- inverted) data and equipment using inverted data. Note that the recommended method for both Caller and Callee is to use normal data. Upon call establishment, the receiver should program their CPE to accept normal data. If a correctly-framed HDLC Sklower [Page 5] Draft Encapsulation Determination August 1993 packet with a correct CRC (hereafter referred to as a "good" frame) is received, the procedures described above should be followed. If, after 10 seconds, no "good" frame has been received, the hardware should be reprogrammed to accept inverted data. If a "good" packet has been received, handle as above. Otherwise, wait 10 seconds and revert to inverted. Continue this as long as makes sense. One thought on total time is that, at this point, the call has been established. Thus, you will likely be charged for 1 minute anyway, so you might as well try for a minute. 8. Out of Band Signaling {Warning - Meta paragraph. At the last IETF meeting, it was agreed that somebody would approach ANSI for obtaining a code point for the LLC-IE byte 7 "user information layer 3 protocol" that would indicate PPP. I probably have botched this section but I'm going to include it to make it easier for whoever edits this next}. 8.1. Caller's Requirements In cases where the LLC information element is available and can be transmitted to be relied on end to end, and the sys- tem wishes to communicate using the RFC-1294 encapsulation, a system MUST encode the LLC-IE in the following way in his setup message: Sklower [Page 6] Draft Encapsulation Determination August 1993 8 7 6 5 4 3 2 1 ----------------------------------------------------------- 0 1 1 1 1 1 0 0 0 Low Layer Compatibility Octet 1 ----------------------------------------------------------- . . . ----------------------------------------------------------- 1 1 0 0 1 1 1 1 Octet 6 ext layer 2 ident Core Aspects of Q.922 (Frame Relay) -or- 1 1 0 0 1 1 1 0 Octet 6 ext layer 2 ident Full Q.922 (LAPF) ----------------------------------------------------------- 1 1 1 0 1 0 1 1 Octet 7 ext layer 3 ident ISO/IEC TR 9577 (Protocol Identifi- cation in the Network Layer) ----------------------------------------------------------- In cases where the system wishes to exchange information using RFC-1356/X.25 PLP/LAPB a system MUST encode the LLC-IE in the following way in his setup message: 8 7 6 5 4 3 2 1 ----------------------------------------------------------- 0 1 1 1 1 1 0 0 0 Low Layer Compatibility Octet 1 ----------------------------------------------------------- . . . ----------------------------------------------------------- 1 1 0 0 0 1 1 0 Octet 6 ext layer 2 ident CCITT Recommendation X.25 link level ----------------------------------------------------------- 1 1 1 0 0 1 1 0 Octet 7 ext layer 3 ident CCITT Recommendation X.25 packet level ----------------------------------------------------------- 8.2. Callee's Algorithm If the LLC-IE exactly matches that generated by the caller's algorithm, the system SHOULD proceed according to the encap- sulations spelled out here. The callee MAY inspect the first correctly framed HDLC packet to see that it matches the encapsulation scheme described. If the LLC-IE contains other values, the system SHOULD pro- ceed according to the ``wait-and-see'' algorithm described Sklower [Page 7] Draft Encapsulation Determination August 1993 above. However, system MAY refuse the connection, or the system MAY make the following inferences: If the User infor- mation layer 3 protocol is 0 1 0 0 0 (ISO 8348 Connection oriented network service), the system MAY assume that RFC-1356/X.25 operation is requested. If the User informa- tion layer 3 protocol is 0 1 0 0 1 the system MAY assume that only ISO 8473 packets will be routed, (just as if an X.25 call had been placed with a CUD of 81). A system MAY also assume that octet 7 with a value of 0 1 1 1 0 indicates a desire to encapsulate according to RFC-1294. 9. Interoperability Defaults and Recommendations. It is REQUIRED that all systems wishing to exchange multi- protocol datagrams over circuit mode ISDN implement the PPP protocol. Such systems encapsulate packets MAY encapsulate packets according to any of the metchods delineated here: PPP, Frame Relay, or X.25. (Systems cannot expect to inter- operate if they use PPP inside V.120, or transmit IP directly inside HDLC framed packets). If a calling system does not get a response to its initial choice of encapsula- tion, it MUST eventually try using the PPP encapsulation. 10. Addressing Stated Requirements of Earlier Work 10.1. Leifer et al A goal of this proposal was to be able to use bandwidth on demand, and obtain the advantage of using multiple B chan- nels for transmitting traffic between two hosts. There are a number of possible ways of doing this which will be dis- cussed at length in a separate draft.[12] 10.2. Murakami et al A major concern of this paper was the use of out-of-band signaling to negotiate compatible configuration parameters. It is the contention of this author that any parameter need- ing to be negotiated in this scheme should be able to be done so by PNMI, and if it can't then PPP should be extended to negotiate that parameter. 11. References [1] Leifer, D., Sheldon, S., and Gorsline B., "A Subnetwork Control Protocol for ISDN Circuit-Switching" IPLPDN Working Group, Internet Draft (Expired), March 1991. [2] Muramaki, K., and Sugawara, T., "A Negotiation Protocol for Mutliple Link-Protocol over ISDN Circuit Switch- ing", IPLPDN Working Group, Committee Document, May Sklower [Page 8] Draft Encapsulation Determination August 1993 1992. [3] Romkey, J.L., "A Nonstandard for Transmission of IP Datagrams over Serial Lines: SLIP." Network Working Group, RFC-1055, June 1988. [4] Simpson, W., "The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to- Point Links", Network Working Group, RFC-1331, May 1992. [5] McGregor, G., "The PPP Internet Protocol Control Proto- col (IPCP)" Network Working Group, RFC-1332, May 1992. [6] CCITT, "Recommendation V.120: Data Communications over the Telephone Network" Blue Book, ITU 1988 [7] Malis, A., Robinson, D., Ullman R., "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode", Net- work Working Group, RFC-1356, August 1992. [8] Bradley, T., Brown, C., and Malis, A., "Multiprotocol Interconnect over Frame Relay", Network Working Group, RFC-1294, January 1992. [9] Sklower, K. and Frost, C. "Parameter Negotiation for the Multiprotocol Interconnect" IPLPDN Working Group, Committee Document, November 1992. [10] Boland, F., editor, "Stable Implementation Agreements for Open Systems Interconnection Protocols: Version 2 Edition 1", NIST Workshop for Implementors of OSI, NIST, February 1989. [11] Internation Organisation for Standardization, "HDLC - Description of the X.25 LAPB-Compatible DTE Data Link Procedures", Internation Standard 7776, 1988 [12] Sklower, K., "A Multilink Proceedure for Synchronizing the transmission of Multi-protocol Datagrams", Internet Draft, CNRI, April 1993 12. Author's Address [13] Simpson, W., "PPP over ISDN", Internet Draft, CNRI, August 1993. Keith Sklower Computer Science Department 570 Evans Hall University of California Berkeley, CA 94720 Sklower [Page 9] Draft Encapsulation Determination August 1993 Phone: (510) 642-9587 Email: sklower@cs.Berkeley.EDU 13. Expiration Date of this Draft February 16, 1994 Sklower [Page 10]